The present invention relates generally to managing user authorization levels.
Many software applications employ user authorization levels to control items such as user access and user permission levels for those applications. While helpful in preventing unauthorized access, such systems have a number of drawbacks. For a large application user base, the administrator(s) of those application(s) can be overwhelmed by numerous requests to add new users and/or to change the authorization levels of existing users of the applications(s). Additionally, if the user base extends to different work groups or even different cities from where the application administrator(s) are located, there are security issues where the administrator(s) must validate that the user is indeed an employee requiring application access and in many cases, the application administrator(s) will not know when to disable a user's access when the user is no longer employed by the company or they change to a different job within the company that does not require access to the application(s). Also, another security issue is the validation of permission levels for users in other work groups or cities where those users are not personally known by the application administrator(s).
Some application users require authorization levels for accessing multiple software applications (in a suite of applications) with the correct permission levels for each application. Enabling authorization levels (e.g., user access and permission) for multiple software applications can be a time-consuming process for an application administrator to handle even for a single user.
A new user may take over the job of an existing application user (i.e., the existing user has retired and a new person takes their job). This requires a time consuming amount of work for the application administrator(s) to duplicate the exact same application access and permission levels for the new user to match the access and permission levels of the outgoing user. If users need access to multiple software applications (in a suite of applications) with the correct permission levels for each application, then a problem exists in providing consistent standardized access and permission levels based on work group or job title. In addition, if the application access was created on an individual application basis, and one or more required applications were forgotten on the initial set-up of a user, then the user and application manager would have to go through the process of setting up access and permissions for those application(s) at a later time.
An additional problem for large application user groups is that certain types of users (company, contractor, application provider, etc.) may require certain restrictions or permissions based on their user type. An example is that a company user may need access to all application database records with no restrictions placed on viewing these records. However, a contractor user may need to have restrictions placed to protect proprietary information (such as pricing or another contractor's information) within the application databases. In addition, the application provider may need full administrative rights in order to maintain the application(s).
Many large companies have applications that require user IDs and passwords for security reasons. Application databases may require the current employee information must be entered in the application database prior to granting access to an application. This can be a time-consuming process to type employee information in the application database.
Existing systems attempt to manage employee authorization levels by establishing user profiles. The user profiles are used to define permissions such as read, write and execute permission. Permissions may be defined for an individual or for a group. Creation and management of these user profiles, however, requires significant involvement from an administrator.